Application code (e.g., firmware) for peripheral devices (e.g., Universal Serial Bus (USB) compatible devices) is commonly stored in an on-board non-volatile memory device, such as an Electrically Erasable Programmable Read Only Memory (EEPROM) external to a microcontroller unit (MCU) of the peripheral device. Although employing an external EEPROM provides good field programmability and upgrade capability, downloading the firmware during the Micro Controller Unit's (MCU) power-on boot time is time consuming for some applications. As defined by the Universal Serial Bus (USB) standard, version 2.0 (USB 2), a bus powered device is allowed to spend one hundred milliseconds (100 ms) for external descriptor and firmware downloading after power up and prior to signal connect. For many applications this is not enough time.
For example, the ubiquitous, low cost and widely available I2C EEPROM can be used to store firmware for USB compatible devices. However, the typical I2C EEPROM has either a 100K bit/sec or 400K bit/sec data transfer rate. Thus, a typical 32K-byte firmware download takes 720 milliseconds to complete even when using the 400K bit/sec data transfer rate, which far exceeds the maximum 100 millisecond time requirement allowed by the USB specification.
A current solution for USB devices requires a dummy boot loader and host utility/driver software to first enumerate the dummy boot loader which then starts the firmware downloading process. Enumeration is the process of determining what device has just been connected to the bus and what parameters it requires such as power consumption, number and type of endpoint(s), class of product, etc. The host will then assign the device an address and enable a configuration allowing the device to transfer data on the bus.
After the dummy boot loader finishes the downloading, it performs a pseudo disconnect and re-connect to the USB host controller to re-enumerate the USB peripheral device to a device that matches the functionality defined by the firmware downloaded. A disadvantage of this solution is that the special dummy boot loader requires additional boot code development. Another disadvantage to this solution is that it is necessary to develop a custom host/utility driver software for each operating system. Yet another disadvantage of this solution is potential side effects from the dynamic disconnect and reconnect to the USB host controller because different operating systems can react differently with respect to software timing issues.